Open-source microscope add-on for structured illumination microscopy

Super-resolution techniques expand the abilities of researchers who have the knowledge and resources to either build or purchase a system. This excludes the part of the research community without these capabilities. Here we introduce the openSIM add-on to upgrade existing optical microscopes to Structured Illumination super-resolution Microscopes (SIM). The openSIM is an open-hardware system, designed and documented to be easily duplicated by other laboratories, making super-resolution modality accessible to facilitate innovative research. The add-on approach gives a performance improvement for pre-existing lab equipment without the need to build a completely new system.

Minor points: 1.I could not find any information about the objective(s) in the main text or methods section.The only thing I know about the microscopes are they are "IX71 and IX81, Olympus".Please provide more detailed information on objective type, magnification, numerical aperture (NA) and immersion medium.2. Camera information is also missing.Brand, model, pixel size of the images?3. Line 61 and Supplementary Figure 4: It is unusual that in openSIM, "4 angles are used and 14 different patterns".It is well known that in linear 2D SIM, 3 angles in increments of 60° can fill the lateral Fourier plane.Each direction only needs 3 phases (i.e., pattern shifts) to decode the 0th and ±1st orders in frequency domain.That is 3 angles × 3 phases = 9 raw images in total.But openSIM uses 14 images, which would appear to increase overall exposure time and introduce unnecessary photobleaching.The authors need to explain why they choose 4 angles in increments of 45° with 3 patterns for 0° and 90° and 4 patterns for 45° and 135°.4. Line 76: All full width at high maximum (FWHM) statistics for the PSF should also provide standard deviations (std / sd) and N. 5. Line 111-113, the authors claim that "LEDs sources, in combination with a spatial light modulator allow for a much simpler optical design, therefore the openSIM relies on incoherent LED light sources, and the pattern is generated by projection rather than interference."I do not understand why the pattern is generated by "projection" rather than interference.As openSIM still uses a ferroelectric phase-only SLM instead of a DMD to generate grating-like patterns at the imaging plane, the word "projection" does not make sense to me.My understanding is that diffraction and interference are basic characteristics of light waves.Different light sources have different coherence lengths, which in turn affects the modulation depth at the imaging plane.It is not that SLM produces such fringes due to "projection" rather than "interference".I would be happy if the author could convince me with more physics knowledge, but more detailed and accurate explanation should be provided for this statement in the revision, or simply use 'interference'.6.As a sanity check, please provide at least one Fourier transform amplitude image and indicate the 169 nm<sup>-1</sup> position on it for Wiener reconstruction results shown in Figures or Supplementary Figures.The corresponding Wiener constant value used should also be indicated.7. Does openSIM support time-lapse SIM imaging?If so, please provide at least one movie for live-cell imaging.

Reviewer #2 (Remarks to the Author):
Title: Review of Manuscript "OpenSIM: open source microscope add-on for structured illumination microscopy" I was delighted to review the manuscript titled "OpenSIM: open source microscope add-on for structured illumination microscopy."Having encountered it as a preprint, I was particularly inspired by its potential and considered the possibility of implementing it myself.In our laboratory, we extensively utilize various structured illumination microscopy (SIM) setups that predominantly rely on coherent grid pattern generation using digital micromirror devices (DMDs).Consequently, I was intrigued by the concept of a setup exclusively employing incoherent illumination as it seems to remove the complexity of adjusting laser beams very exactly.
The manuscript effectively presents all the essential information, emphasizing the core concepts.The results, notably the image data, convincingly demonstrate the method's efficacy in reducing background signals and potentially improve the resolution.The associated documentation, which not only encourages replication but also thoroughly elucidates each step, establishes a benchmark for open-source hardware in scientific publications.The inclusion of video documentation is particularly commendable, and the level of detail in the online documentation is highly impressive.
A crucial point highlighted in the manuscript is the lack of integrative open-source systems that enable users to enhance commercially available microscopes, a pertinent issue often leading to redundant device development among different labs.The manuscript could potentially promote this aspect further, emphasizing the potential benefits of standardized interfaces or shared blueprints from manufacturers to foster collaborative adaptations across labs.The authors mention that "higher resolution improvement, due to a higher achievable pattern contrast and overall illumination intensity" is achieved with 2-beam SIM.It would be valuable if the authors could delve into a comparison of the complexity and alignment effort required for constructing an incoherent SIM setup compared to a 2-beam configuration.This analysis appears to be missing from the manuscript.Also a few references and perhaps a comment on the theory behind incoherent SIM would complete the manuscript a bit.
Throughout the manuscript, several questions arose that I would like to address to the authors.
Regarding the statement, "As an open source microscope, we provide detailed documentation and instructions enabling other scientists to build their own openSIM add-on," I am curious about the target audience ("other scientists") of the manuscript.Ultimately, the audience seems to be a multidisciplinary group with a specific interest in biology, possessing a high level of technical acumen and a willingness to craft customized solutions.Although the project has achieved a high level of professionalism for a scientific "product", it remains relatively complex to construct at various points.For our laboratory, this manuscript would serve as an invaluable source of inspiration for building similar instruments, with the necessary information embedded within the instructions.It might be beneficial if the authors could mention or even elaborate on alternative components that could be used to realize the device as the ones mentioned in the text may not be available or too expensive.This leads to my most significant question: "these components are readily available at moderate cost from electronics supply companies and have shown good performance for SIM imaging."The manuscript adeptly demonstrates the construction of a customized video projector, combined with LabVIEW programming, to generate SIM images.Have the authors considered the possibility of directly using an off-the-shelf video projector?This approach might potentially save a substantial amount of effort, time and money.Trigging patterns on the fourth-dimension display is likely much faster than the DMD-based setup shown in a related publication.A comprehensive exploration of this topic would be appreciated.Utilizing an off-the-shelf device could greatly enhance the chances of broader adoption and community engagement.
The mention of "and linked to an open-source community" raises questions about the community's current or potential existence.The Notion document contains a wealth of information, though I experienced some difficulty navigating it due to the absence of a clear hierarchy/visible structure when departing from the main page (Disclaimer: I rarely use Notion).From my experience, it's highly advantageous when individuals can ask questions directly where problems arise.I would anticipate this to be on the GitHub page where production files are located.As of now, the design files appear to be missing, preventing any potential modifications.This, coupled with the closed documentation (precluding pull requests for improving instructions) and the use of LabVIEW as software, somewhat compromises the project's status as fully open-source-a somewhat questionable aspect.Unfortunately, I couldn't execute or test the software for potential issues due to a lack of access to LabVIEW.However, I'm sure developers have put a great effort into making the software robust and useful for biologists.This is what the photos illustrate.
With a stronger emphasis on open-source principles and community creation, an alternative software approach might have been considered.For instance, the authors could have explored options like Micromanager, ImSwitch, or Python-Microscope, many of which support most of the devices used in the setup.Such a shift might encourage wider utilization of the system.There appears to be an omission in Line 185, concerning the mention of laser-cut parts.

Regarding the GitHub Repository:
-The mixture of formats (Notion, PDF, Markdown) for different parts of the documentation can be a bit confusing.It would be helpful to maintain a consistent format for better clarity.
-The chosen license is appropriate.
-Considering using Markdown formatting for documents could enhance readability and consistency.
-Testing/Debugging LabVIEW without significant investment in packages like the "vision" is challenging/impossible -The file "openSIM_labview_withoutSpecVIcamera_V2.0"appears to be empty -The user manual ("userManual_openSIM_software_V2.0.pdf") is well-written and exemplary in its step-by-step approach.However, considering using Markdown instead of PDF could improve accessibility.
-Additionally in the same file: o Clarify how the objective is mounted to DAQ within the user manual.o Specify the data format exported, such as OME-TIFF, and provide guidance on compatibility with other software.Offering an example dataset would be valuable.o Exploring the possibility of exporting the LabVIEW software as an executable could enhance usability.o Clarify the purpose of indicator "I4" and its relationship with the SLM triggering the camera.o The user interface is well-designed for biologists and allows for easy control.o Address the unclear functionality of "Enabling/Disabling test mode."If possible, allow running the software fully without hardware or rename it to "LED Testing mode."o Consider populating the troubleshooting section, offering solutions to potential issues users might face, such as wrong hardware ports or error messages.o Clarify why certain options are grayed out in the settings, such as EM gain, AOI width, AOI height, and AUX output source.o Provide clarity on which cameras may support LabVIEW integration among the potential addons.o Consider adding a timelapse mode to the GUI.

Regarding the Electronics:
-A concise readme for the electronics section would aid in understanding the files.
-Ensure that source files are included in the electronics section.
-Provide clarification on how the LED is switched and amplified in the electronics design.
-Consider using thicker wire lines on the PCB for larger signals like those for the fan and LED.
-Adding LED spectra to match fluorophores would be beneficial, either here or in the manuscript.

Regarding the Notion Website:
-In the image gallery, clarify whether the 4 angles and 14 patterns shown represent a single reconstruction or serve as examples.
-Provide the option for raw data alongside images.
-Address the issue of images appearing small in the Notion website; consider incorporating scaling options for better visualization.
Regarding the Videos for Rebuilding the Structure: -The videos are well-executed and comprehensive, making it feasible to recreate the setup from my technical point of view -Question the use of a potentially expensive DIY projector; suggest considering customization of a DMD projector along with LED modifications for cost-effectiveness.
In conclusion, I find the manuscript titled "OpenSIM: open source microscope add-on for structured illumination microscopy" to be a valuable contribution to the field of microscopy, particularly in its pursuit of open-source solutions.The work showcases significant progress in reducing background signals through structured illumination microscopy and provides comprehensive documentation that encourages replication and understanding.
However, there are some critical aspects that merit attention before publication: 1.Openness and Source Availability: Given the emphasis on open-source principles throughout the manuscript, it's imperative that the associated sources and design files are equally open and accessible.Addressing the missing design files is crucial to upholding the integrity of the opensource idea.Without these files, replicating and building upon the project becomes challenging if minor modifications have to be made in order to adjust to different hardware for example.Exemplary raw data would also be helpful.

Documentation Format:
The combination of various formats, including Notion, PDF, and Markdown, within the GitHub repository can lead to confusion for users seeking clear guidance.Standardizing the format and considering using Markdown for better readability could significantly improve the user experience.I suggest hosting most of the technical documentation on Github so that users can also interact through discussions or issues.
3. LabVIEW Dependence and Community Engagement: While the LabVIEW-based approach is valid, it does limit accessibility for those without access to LabVIEW licenses.To align with the open-source philosophy and foster broader community engagement, exploring software alternatives like Micromanager, ImSwitch, or Python-Microscope, which support a wider range of hardware, could be advantageous.This is a huge thing to ask for and I understand if this is not possible, but perhaps authors find a minimal working prototype that is e.g.provided by micromanager.
Considering these points, I recommend the manuscript for publication in principle, with the understanding that these key issues need to be addressed to ensure the manuscript's alignment with the open-source philosophy and to enhance its reproducibility and accessibility.By actively addressing these concerns, the authors have the potential to contribute even more significantly to the open-source microscopy community and advance the field of structured illumination microscopy.

Reviewer #3 (Remarks to the Author):
I have reviewed the manuscript entitled "OpenSIM: open source microscope add-on for structured illumination microscopy" by Hannebelle et al.The manuscript describes a system for achieved structured illumination microscopy based on low cost components (3D printed parts, electronics, optics) accompanied by detailed instructions in a separated website that should enable interested readers to replicate such aa microscope.The novelty of this manuscript is moderate.It mainly depends on the fact that a very cost efficient, 3D-printable version of a SIM microscope is being demonstrated.The main paper itself only provides a general description of the system and demonstrates this by a series of examples across several different length scales.More details are found in the supplementary information file, as well as on the dedicated web site.While I am typically all in favor of publishing the information for such open systems in a high impact journal, I still have a few concerns about this manuscript in particular: Reviewer #1 -major points: 1.1) In lines 106-117, the authors claimed that "Our goal in designing the openSIM add-on was not to compete with the most advanced SIM systems that …" My main concern related to this statement is that a lot of technical details are not discussed in this manuscript, especially compared to convenEonal SIM systems.For example, the authors used high-power LEDs with much shorter coherence lengths as the excitaEon light sources instead of single-mode lasers, at the expense of lower modulaEon depth and likely coarser graEng frequency applied on SLM.In general, lower modulaEon depth and coarser graEng frequency leads to worse Wiener reconstrucEon (lower SNR, resoluEon etc.), which are important points that are not explained in the manuscript.Several other points deserve further clarificaEon: 1.There are no pinholes to block unwanted diffracEon orders from the SLM.Are pinholes unnecessary in this setup, or are there no other diffracEon orders aWer the SLM? 2. There is no polarizaEon rotator to change the polarizaEon states of the diffracted beams aWer the PBS to maintain s-polarized illuminaEon at the sample for all 4 different angles.What effect is this likely to have on the quality of reconstrucEon?I strongly suggest the authors clarify the consequences of the key differences between openSIM and "state-of-the-art SIM systems", perhaps in the discussion.Besides reducing costs, what are the beneficial or adverse effects of these modificaEons and simplificaEons?The answers to these quesEons will be important for readers to decide if they choose to clone openSIM, buy a commercial SIM or build a more advanced SIM system.
We thank the reviewer for raising these ques3ons and giving us an opportunity to highlight be9er the differences between our OpenSIM and more tradi3onal SIM systems.These are the key points we understood from this reviewer's comment: 1) technical/op3cal aspects are not discussed sufficiently / need further clarifica3on, 2) discussion of difference between openSIM and 'state-of-the-art' SIM and 3) consequences of design choices.
We addressed these comments individually in the following:

Difference of working principle/op=cal design of openSIM compared to conven=onal SIM systems
The main difference between the op3cal design of openSIM and other conven3onal systems is the excita3on pa9ern genera3on approach and the use of an incoherent light source.Conven3onal SIM systems use high-frequency fringe pa9erns formed by interference of diffrac3on beams in the sample plane to illuminate the sample.For this, commonly LCOS SLMs in phase-only mode are used.Coherent light is collimated onto the SLM, which serves as a phase gra3ng, leading to the diffrac3on beams.The illumina3on pa9ern is then created by the interference of two diffrac3on beams (for 2D SIM) or three diffrac3on beams (for 3D SIM) in the sample plane.The approach for the illumina3on pa9ern forma3on of openSIM follows a non-diffrac3on or interference-based method using non-coherent light, described in [1][2][3][4][5] , in which an image of the SLM is formed directly in the sample plane instead of being created by interference of diffrac3on beams.For this, the LCOS SLM is placed in the primary image plane of the microscope and used in combina3on with a polarizing beam spli9er (PBS) in amplitude mode to serve as a computer-controlled binary mask.The microdisplay is imaged onto the sample via a polarizing beam spli9er, an addi3onal tube lens and the microscope's objec3ve.à We included this informa3on in a concise format in the interest of readability, highligh3ng the key details within the manuscript's discussion and methods sec3ons.Addi3onally, we presented a comprehensive version of this informa3on, along with addi3onal schema3cs, in the documenta3on (corresponding page of openSIM website, sec3on 'LCOS in amplitude mode', 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems').

Advantages / disadvantages of used op=cal design compared to conven=onal SIM systems
One of the primary benefits of employing direct imaging of the pa9ern into the sample plane, as opposed to systems relying on interference, lies in the inherent simplicity of the op3cal setup with a small number of basic op3cal components and reduced demands for precise posi3oning and alignment of these op3cal elements, making the overall system more robust and less prone to alignment-related challenges.An addi3onal advantageous facet of this setup lies in the flexibility regarding the usable wavelengths and desired pa9erns, enabling the switching between mul3ple wavelengths and the use of different pa9ern orienta3on angles.The SLM possesses the capability to create arbitrary binary pa9erns, and notably, the spa3al frequency of these pa9erns remains independent of the wavelength in use 3 .Moreover, the op3cal design does not necessitate components with a wavelength-or pa9ern orienta3on-dependent layout (e.g.phase-plane masks, rota3ng polarizer).As a consequence, such components demand for either a setup with preset configura3ons (i.e.accommoda3on of only one fixed wavelength and set of pa9ern orienta3ons) or more complex op3cal components.A primary objec3ve in SIM imaging is to achieve the highest possible contrast (degree of modula3on) in the excita3on pa9ern at the sample plane, aiming for an op3mal signal-to-noise ra3o 6 .Despite the descripted advantages of the chosen op3cal design of openSIM, it presents certain drawbacks that poten3ally result in a reduced image contrast.Placing the microdisplay in the image plane for direct pa9ern imaging into the sample plane results in an inefficient use of the illumina3on light.Nonetheless, the employed high-power LEDs possess sufficient brightness to offset this inefficiency 1 .Furthermore, polarizing elements such as the LCOS display and the PBS cube exhibit subop3mal polariza3on proper3es leading to a decrease of the pa9ern contrast 7 .à We included this informa3on in a concise format in the interest of readability, highligh3ng the key details within the manuscript's discussion and methods sec3ons.Addi3onally, we presented a comprehensive version of this informa3on in the documenta3on (corresponding page of openSIM website, sec3on 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems').

Omission of pinholes in op-cal design to block unwanted diffrac-on order from the SLM Omission of polariza-on rotator in op-cal design to change the polariza-on states of the diffracted beams to maintain s-polarized illumina-on at the sample for all 4 different angles
For SIM systems in which the illumina3on pa9ern is generated based on interference, the appropriate handling of diffrac3on orders and maintenance of polariza3on states is crucial.To a9ain the highest level of modula3on, it is beneficial to obstruct the zero-diffrac3on order coming from non-diffracted light for 2D SIM 6 and unwanted higher diffrac3on orders caused by the finite-sized pixels of the SLM 8 .This can be achieved by a mask with pinholes at the appropriate posi3on in the illumina3on path (i.e.pupil plane) [8][9][10] .Furthermore, for the interference of beams, the light needs to have the same polariza3on 11 .To maximize the pa9ern contrast, it has to be assured that the illumina3on light is s-polarized for all pa9ern orienta3ons 9 , which can be achieved by a rota3ng polarizer 8,9,11 or a pa9erned polarizer 10 .The implementa3on of such a pupil-plane mask and polarizer can be challenging since they have to be designed and precisely posi3oned according to the used wavelength and pa9ern orienta3ons.For SIM system based on direct imaging of pa9ern into the sample plane, pinholes to block unwanted diffrac3on and polariza3on rotators to maintain s-polarized illumina3on, normally necessary for pa9ern genera3on based on interference, are not required, which is reducing the complexity of the op3cal design.Although a pinhole may not be considered an essen3al component in our case, it could poten3ally enhance the quality of the pa9ern by serving as a spa3al filter and effec3vely blocking unwanted higher diffrac3on orders or unwanted stray light from other sources.Nevertheless, the integra3on of a pinhole would necessitate the inclusion of supplementary op3cal elements, demanding precise posi3oning within the op3cal system, and would result in a more complex op3cal path.Since we are aiming for a simple and compact add-on, easily mountable to microscopes which o^en have setupinherent space constrains, we opted not to incorporate an addi3onal pinhole to maintain the simplicity and compactness of our design.However, undesired diffrac3on orders higher than the 1 st order stemming from the finite size of the microdisplay's pixel are naturally blocked by the design of the 3D printed op3cs block.à We included this informa3on in a concise format in the interest of readability, highligh3ng the key details within the manuscript's discussion and methods sec3ons.Addi3onally, we presented a comprehensive version of this informa3on in the documenta3on (corresponding page of openSIM website, sec3on 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems').

Use of incoherent light source (disadvantages/advantages, limita=ons)
A main factor influencing the resolving performance of SIM is the highest achievable illumina3on pa9ern contrast.Non-coherent systems [1][2][3][4][5]12 such as openSIM, which employ incoherent light from high power LEDs, exhibi3ng a reduced maximal a9ainable contrast which consequently leads to a diminished enhancement in resolu3on when compared to coherent systems [8][9][10][13][14][15][16] u3lizing coherent laser light. Whle for coherent illumina3on SIM, the coherent op3cal transfer func3on applies, where the pa9ern contrast remains constant with increasing spa3al frequency, for incoherent illumina3on SIM, the incoherent op3cal transfer func3on applies, causing pa9ern contrast to decrease as spa3al frequency increases 17 , leading to a diminished contrast for high-frequency pa9erns.Nevertheless, despite the poten3al higher achievable resolu3on of coherent illumina3on SIM, the use of coherent light sources comes with several drawbacks.Since, we were aiming to provide an inexpensive and compact system which is straigh`orward to reconstruct, aspects such as cost-effec3veness, availability, small dimensions and safety of the used components were of main importance.Lasers are expensive, spacious and only available for certain wavelengths, whereas LEDs are less limited in terms of available wavelengths, making them a cost-efficient compact choice, simplifying the incorpora3on of mul3ple excita3on channels and the exchange of the light source in order to match the different spectra of other fluorophores.Moreover, lasers are generally less safe to use than LEDs as they pose a higher risk of eye damage due to their high intensity.Furthermore, in contrast to LEDs which exhibit a low spa3al coherence, the high coherence of laser light can be problema3c due to stray interference pa9erns.This can be circumvented by spa3ally scrambling the light, however, increasing complexity and costs 6 . à We inclued this informa3on in a concise format in the interest of readability, highligh3ng the key details within the manuscript's discussion sec3ons.Addi3onally, we presented a comprehensive version of this informa3on in the documenta3on (corresponding page of openSIM website, sec3on 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems').

Reviewer #1 -minor points:
1.2) I could not find any informaEon about the objecEve(s) in the main text or methods secEon.The only thing I know about the microscopes are they are "IX71 and IX81, Olympus".Please provide more detailed informaEon on objecEve type, magnificaEon, numerical aperture (NA) and immersion medium.Camera informaEon is also missing.Brand, model, pixel size of the images?We apologize for this oversight on our part.An 'image acquisi3on' paragraph was added to the methods sec3on in the manuscript containing informa3on about the used objec3ves and cameras during image acquisi3on.
Manuscript methods sec3on 'Image acquisi3on': The fixed mouse intes3nal organoid, the live zebrafish embryo, the macrophages infected with Mycobacterium smegma3s bacteria and the fixed ac3n-stained COS-7 cells were imaged using a 20x and 100x (1.3 NA, oil immersion) objec3ve.The 100nm bead sample and the fixed bovine pulmonary artery endothelial cells were imaged with a 100x objec3ve (1.3 NA, oil immersion).For the image acquisi3on an Andor Zyla 4.2 Plus camera (pixel format 1048x1048) and an Andor iXon3 camera (pixel format 1024x1024) were used.We provide example data sets of the fixed 100nm bead sample, fixed bovine pulmonary artery endothelial cell sample and the live zebrafish sample on Zenodo including the raw data and the reconstructed data with corresponding informa3on about the used parameter segng during image acquisi3on and image reconstruc3on.4: It is unusual that in openSIM, "4 angles are used and 14 different paderns".It is well known that in linear 2D SIM, 3 angles in increments of 60° can fill the lateral Fourier plane.Each direcEon only needs 3 phases (i.e., padern shiWs) to decode the 0th and ±1st orders in frequency domain.That is 3 angles × 3 phases = 9 raw images in total.But openSIM uses 14 images, which would appear to increase overall exposure Eme and introduce unnecessary photobleaching.The authors need to explain why they choose 4 angles in increments of 45° with 3 paderns for 0° and 90° and 4 paderns for 45° and 135°.An 'illumina3on pa9ern' sec3on was added to the methods sec3on in the manuscript giving general informa3on about SIM illumina3on pa9ern, pa9ern design considera3ons and explana3on about the chosen pa9ern sequences.Manuscript methods sec3on 'Illumina3on pa9ern': In order to obtain nearly isotropic resolu3on improvement in 2D linear SIM, the periodic pa9ern needs to be shi^ed through three phases (120° to each other) and for each of three orienta3ons (0°, 60°, 120°), yielding nine raw images 13 .In our experiments, a sequence of periodic line pa9erns with 3 orienta3on angles and 4 images per angle (12 different pa9erns in total) was used, in total resul3ng in a homogenous illumina3on.The set of pa9erns was designed according to Lukeš et al. 2 so that the pa9ern for different orienta3on angles have a similar mark-to-area ra3o (MAR) (i.e.frac3on of the illumina3on area) 6 , and spa3al frequency.Because the pixels on the microdisplay have a square shape, addi3onal pa9erns were used in the diagonal direc3ons to ensure even coverage across the en3re image while maintaining a roughly consistent spa3al frequency for the pa9erns 2 .While three angles are sufficient for SIM image reconstruc3on, using more angles can poten3ally increase the spa3al resolu3on and improve the robustness and accuracy of the image reconstruc3on.Nevertheless, this comes at the expense of extended acquisi3on 3mes, increased photobleaching and computa3onal cost.We thus used a pa9ern repertoire with an addi3onal angle orienta3on (4 angles and 3 or 4 images per angle, 14 different pa9erns in total) for non-biological or fixed samples where photobleaching is not of importance.

1.3) Line 61 and Supplementary Figure
1.4) Line 76: All full width at high maximum (FWHM) staEsEcs for the PSF should also provide standard deviaEons (std / sd) and N. Standard devia3on and N were added to all FWHM value in figure 2 and supplementary figure 8.
1.5) Line 111-113, the authors claim that "LEDs sources, in combinaEon with a spaEal light modulator allow for a much simpler opEcal design, therefore the openSIM relies on incoherent LED light sources, and the padern is generated by projecEon rather than interference."I do not understand why the padern is generated by "projecEon" rather than interference.As openSIM sEll uses a ferroelectric phase-only SLM instead of a DMD to generate graEng-like paderns at the imaging plane, the word "projecEon" does not make sense to me.My understanding is that diffracEon and interference are basic characterisEcs of light waves.Different light sources have different coherence lengths, which in turn affects the modulaEon depth at the imaging plane.It is not that SLM produces such fringes due to "projecEon" rather than "interference".I would be happy if the author could convince me with more physics knowledge, but more detailed and accurate explanaEon should be provided for this statement in the revision, or simply use 'interference'.openSIM follows a different approach compared to conven3onal SIM systems which indeed create the excita3on pa9ern by interference of diffrac3on beams o^en by u3lizing a LCOS SLM.openSIM also uses a LCOS SLM to generate the illumina3on pa9ern but in amplitude mode instead of phase-only mode.In contrast to interference-based systems, openSIM generates the pa9ern by directly forming an image of the microdisplay, which is placed in the primary image plane of the microscope, in the sample plane.In this context (forma3on of an image of the microdisplay in sample plane) the usage of the term projec3on is adequate in our opinion.But indeed, the different working principle of openSIM compared to conven3onal SIM was not explained sufficiently.To avoid any ambiguity and to emphasis the differences in the working principle and used components compared to conven3onal systems, more informa3on about the pa9ern genera3on were added to the manuscript discussion and methods sec3on (see above) and a detailed explana3on with schema3cs was added to the documenta3on (corresponding page of openSIM website, sec3on 'LCOS in amplitude mode', 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems')

1.6) As a sanity check, please provide at least one Fourier transform amplitude image and indicate the 169 nm-1 posiEon on it for Wiener reconstrucEon results shown in Figures or Supplementary Figures. The corresponding Wiener constant value used should also be indicated.
A figure (supplementary figure 12) with the Fourier transforms of an SIM image and corresponding WF image with circular lines indica3ng the approximately achieved resolu3on was created and added to the manuscript.The corresponding Wiener constant used for image reconstruc3on was indicated.The used Wiener constant was indicated in the image reconstruc3on parameter read-me file for all the exemplary datasets.

1.7) Does openSIM support Eme-lapse SIM imaging? If so, please provide at least one movie for livecell imaging.
The openSIM so^ware did not support 3me-lapse imaging so far, but we implemented a 3me-lapse mode within the scope of the revision process (see supplementary figure 5).We have added a sec3on to the user manual explaining the 3melapse func3onality of the so^ware (see supplementary figure 5).We have not acquired 3me-lapse images so far.

2.1) Openness and Source Availability: Given the emphasis on open-source principles throughout the manuscript, it's imperaEve that the associated sources and design files are equally open and accessible.
Addressing the missing design files is crucial to upholding the integrity of the open-source idea.Without these files, replicaEng and building upon the project becomes challenging if minor modificaEons have to be made in order to adjust to different hardware for example.Exemplary raw data would also be helpful.We apologize that the segng of the openSIM GitHub repository, containing the design files, was accidently not yet set to public in the beginning of the review process leading to access problems and that there was a file missing.We now assured that all design files necessary for building up openSIM are uploaded and publicly accessible.
We uploaded exemplary raw datasets of different sample types (100nm beads, fixed tubulin, zebrafish z-stack) onto Zenodo containing the raw data and reconstructed data with corresponding image acquisi3on and image reconstruc3on parameter.

2.2) DocumentaEon Format: The combinaEon of various formats, including NoEon, PDF, and
Markdown, within the GitHub repository can lead to confusion for users seeking clear guidance.Standardizing the format and considering using Markdown for beder readability could significantly improve the user experience.I suggest hosEng most of the technical documentaEon on Github so that users can also interact through discussions or issues.We thank the reviewer for these sugges3ons.We partly agree with the reviewer's comments that the use of various formats (PDF, pages on No3on, read-me files on GitHub) and the use of different pla`orms (No3on, GitHub) can poten3ally lead to unclarity about the documenta3on structure and where to find specific content.However, we indeed considered several formats and pla`orms (lab webpage, GitHub repository with read-me files and internal wiki, Github webpage, No3on) to host our documenta3on and weighted the advantages and disadvantages before deciding for one.We consciously chose each op3on due to its benefits in the specific applica3on in contrast to the other op3ons.In the end we decided to use a website (No3on) for informa3on about the assembly, opera3on and background theory (all informa3on) and a repository (GitHub) where all technical design files are provided (all files).The primary reason for using No3on is the simple handling without the need for any coding experience, the straigh`orward op3on to publicly share the content as a webpage and to add editors to the No3on project enabling other user to modify the content of the documenta3on.We considered to host the documenta3on on a Github webpage which enables users to directly modify the documenta3on or to fork the underlying repository.However, in order to do the user requires addi3onal knowledge about the structure of the repository and basic knowledge about the used syntax making any modifica3ons more complicated.A GitHub repository was chosen to upload all the technical design files since it allows the user to easily download the files individually or to fork the whole repository.Despite the lack of version control for CAD files or LabVIEW, GitHub offers be9er op3ons to track the versions of the uploaded files.
In response to the reviewer's comments, we improved the clarity and naviga3on of the documenta3on in the following way: In order to present the structure of the documenta3on and to guide the user to the different parts of the documenta3on we added more informa3on about the structure and content with a corresponding schema3c to the openSIM webpage (corresponding page of openSIM website) and addi3onal read-me files explaining the structure of the openSIM repository to the GitHub repository.Furthermore, we added more informa3on to the read-me files on GitHub.On the openSIM No3on webpage, we added more dividers between the different paragraphs and included more toggle structures to differen3ate the different topics on each No3on pages to improve the readability (exemplary openSIM website page with improved structure).

2.3) LabVIEW Dependence and Community Engagement: While the LabVIEW-based approach is valid, it does limit accessibility for those without access to LabVIEW licenses. To align with the open-source philosophy and foster broader community engagement, exploring soWware alternaEves like
Micromanager, ImSwitch, or Python-Microscope, which support a wider range of hardware, could be advantageous.This is a huge thing to ask for and I understand if this is not possible, but perhaps authors find a minimal working prototype that is e.g.provided by micromanager.We thank the reviewer for this comment and agree with the reviewer that the required LabVIEW licenses are a significant hurdle for people who do not have access to site licenses.To share an opensource project with a wide community while providing users the freedom to debug and modify the so^ware, the most suitable choice is to distribute a so^ware developed using an open-source programming language.However, this requires that the user has experience with coding and knows the used programming language.Furthermore, the user needs to understand the structure of the so^ware, which is more complicated when the so^ware contains a GUI, event-based structure and communica3on with external hardware devices.
Our goal with our open hardware projects is to not only make it easy for people to copy and use, but also to modify and expand on.Making the so^ware easy to understand and modify is a big part of that.The "beauty" of LabVIEW is that it enables seamless connec3on of the so^ware to data acquisi3on hardware, which is much more challenging for novices in Python or C. In our experience, it is much easier for non-instrumenta3on-enthusiasts to learn how to make small modifica3ons in LabVIEW than in other languages.We early on considered wri3ng the so^ware in Python, and also looked into micromanager.However, we found that this would make the so^ware much more difficult to modify for novices.Na3onal instruments now offers also a LabVIEW Community Edi3on which is free for non-commercial, non-academic use and has all the capabili3es of the LabVIEW Professional edi3on.
To nevertheless make it possible to for interested readers to build and operate the OpenSIM, even if they not have access to a full LabVIEW license, we now offer three so^ware versions to cater to various user requirements (see corresponding page of openSIM website sec3on 'openSIM so^ware' for more informa3on): • Full LabView Project Versions: For users seeking to modify or customize the so^ware, we provide two full LabView projects.The first version, "openSIM_so^ware_withCameraControl," integrates complete camera control, including image acquisi3on and data handling, specifically designed for Andor Zyla and Andor iXon camera models.• The second version maintains the same structure but omits camera-model-specific components, making it modular and adaptable for other camera models.

• openSIM Applica@on (exe):
To overcome the need for any chargeable licenses and to offer a free so^ware op3on, we created an openSIM so^ware version which allowed us to build an applica3on from it.This so^ware version is designed for user who primarily want to use the so^ware without any need for modifica3on.Running the so^ware version does not require any paid so^ware licenses and is not 3ed to a specific camera model.We func3onally tested this applica3on on an PC without any pre-installed LabVIEW modules to ensure a faultless func3on despite having not any LabVIEW license.We also created an addi3onal user manual (corresponding page on openSIM website) par3cular to this so^ware version with specific installa3on guide and troubleshoo3ng sec3on.In the future we are envisioning to offer an openSIM so^ware in pure Python environment.For this we are planning to use the Python package pymmcore_plus (Python binding for Micromanager with C++ core) to control the camera via a camera specific Micromanager device adapter.The packet pymmcore-widgets offers a set of widgets for the pymmcore-plus package to build a custom user interface.Addi3onal libraires can be used to control the other external devices (e.g.NI-DAQ Python API).Qt designer can be used to develop the event structure.Our first aim would be to provide a python library which offers all the func3onali3es of the current so^ware.In a next step we would build a full GUI which improves the user experiences but also requires addi3onal effort.Nevertheless, as the reviewer already pointed out, developing the openSIM so^ware en3rely within a Python environment from scratch requires a significant amount of work.Thus, we cannot provide this version in the scope of this revision process.Nonetheless, we have a9empted to address this by offering an executable version of the openSIM so^ware.

Reviewer #2 -minor points
We want to thank reviewer #2 for the great amount of helpful and especially detailed feedback about the openSIM website and user manual.Addressing all the comments significantly improved the quality of the documenta3on poten3ally helping to mo3vate others to build up their own openSIM.

2.4) The manuscript could potenEally promote this aspect further, emphasizing the potenEal benefits of standardized interfaces or shared blueprints from manufacturers to foster collaboraEve adaptaEons across labs.
In response to the reviewer's comment, we further elaborated this aspect in the discussion of the manuscript.Manuscript discussion sec3on: We aimed for an add-on which facilitates an effortless integra3on with various commercially available microscopes (such as Olympus, Zeiss, Leica) through the straigh`orward replacement of the tube lens and illumina3on port adapter.However, it's worth considering that the microscope-specific components may limit versa3lity.To poten3ally enhance versa3lity, manufacturers might consider promo3ng standardized interfaces and sharing blueprints to possibly reduce the necessity for custom adapters or connectors.This could offer laboratories a valuable resource for construc3ng and tailoring hardware components which could simplify the setup and streamline workflows for researchers.Consequently, this might encourage more laboratories to openly share their work, foster collabora3ve adapta3ons, and lessen the barriers that could impede other labs from adop3ng open-source devices developed by different labs.

2.5) It would be valuable if the authors could delve into a comparison of the complexity and alignment effort required for construcEng an incoherent SIM setup compared to a 2-beam configuraEon. This analysis appears to be missing from the manuscript. Also a few references and perhaps a comment on the theory behind incoherent SIM would complete the manuscript a bit.
This aspect was also raised by reviewer #1.We thank the reviewer for this comment and agree that the differences in the op3cal design, especially in respect to the underlying theory, complexity and alignment, was not discussed sufficiently.In order to address this comment, we added a comparison of complexity and alignment effort between openSIM and conven3onal SIM systems in a concise format in the interest of readability, highligh3ng the key details within the manuscript's discussion and methods sec3ons.Addi3onally, we presented a comprehensive version of this informa3on in the documenta3on (corresponding page on openSIM website, sec3ons: 'Difference in the op3cal design of openSIM compared to conven3onal SIM systems', 'Differences in the op3cal alignment compared to conven3onal SIM systems').In this context we also elaborate on the theory behind incoherent SIM systems based on interference of diffrac3on beams.We also delve into the advantages and disadvantages of the simple op3cal design of openSIM compared to conven3onal SIM systems both in the manuscript and in more detail in the documenta3on.Please find more informa3on in the response discussed above (1.1).

2.6) It might be beneficial if the authors could menEon or even elaborate on alternaEve components that could be used to realize the device as the ones menEoned in the text may not be available or too expensive.
We added an addi3onal sec3on in the documenta3on (corresponding page of openSIM website, sec3on: 'Note: Alterna3ve products') where we introduce and evaluate different alterna3ve op3ons to the used components, in case the user envisions a cheaper op3on or the specific components is not offered by the manufacturer anymore.However, we cannot guarantee that these alterna3ve components will work as plug-in replacements.

2.7) With a stronger emphasis on open-source principles and community creaEon, an alternaEve soWware approach might have been considered. For instance, the authors could have explored opEons like Micromanager, ImSwitch, or Python-Microscope, many of which support most of the devices used in the setup. Such a shiW might encourage wider uElizaEon of the system.
Please refer to the response discussed above (2.3).

2.8) There appears to be an omission in Line 185, concerning the menEon of laser-cut parts.
Informa3on about the laser-cut parts was added to the methods sec3on of the manuscript.We used a 3mm thick black acrylic sheet for the panels of the enclosure.The sheets were trimmed to the corresponding size with a laser cu9er.

2.9)
The mixture of formats (NoEon, PDF, Markdown) for different parts of the documentaEon can be a bit confusing.It would be helpful to maintain a consistent format for beder clarity.Considering using Markdown formarng for documents could enhance readability and consistency.We acknowledge that the combina3on of various formats can create poten3al confusion.Unfortunately, for the No3on website, we are restricted to using specific pre-defined formagng op3ons.While No3on offers a user-friendly and straigh`orward approach, it comes with the drawback of limited customiza3on choices.Having a PDF version available greatly helps when assembling the instrument in the workshop.We forma9ed the PDF with the inten3on of enhancing the document's structure, clarity and readability, even though the formagng may deviate from the guidelines outlined in the GitHub repository's readme files.We ensured that all readme files on GitHub have the same markdown formagng.

2.10) TesEng/Debugging LabVIEW without significant investment in packages like the "vision" is challenging/impossible
We thank the reviewer for this comment.Indeed, tes3ng and debugging the full LabVIEW projects is not possible without the LabVIEW vision development module.However, the openSIM applica3on can be tested without any chargeable license.We added a table lis3ng all the func3onali3es and debugging/modifica3on op3ons for the individual so^ware versions to the documenta3on (see corresponding page of openSIM website, sec3on 'openSIM so^ware').

2.11) The file "openSIM_labview_withoutSpecVIcamera_V2.0" appears to be empty
We apologize for the missing file.We now assured that all design files necessary for building up openSIM are uploaded and publicly accessible in the GitHub repository.

2.12)
The user manual ("userManual_openSIM_soWware_V2.0.pdf") is well-wriden and exemplary in its step-by-step approach.However, considering using Markdown instead of PDF could improve accessibility.We thank the reviewer for the posi3ve feedback of our user manual and for the sugges3on.We specifically decided to provide the user manual in pdf format since we thought this could simplify using it during an actual imaging session as the pdf can be printed and read parallel in paper format while the openSIM so^ware user interface is open on the screen.

2.13) Clarify how the objecEve is mounted to DAQ within the user manual
More general informa3on about the z-actuator and addi3onal explana3on on how to mount the objec3ve to the z-actuator with schema3cs and annotated images was added to the corresponding sec3on of the user manual (user manual, sec3on 'Appendix -Peripheral components (z-actua3on)') 2.14) Specify the data format exported, such as OME-TIFF, and provide guidance on compaEbility with other soWware.Offering an example dataset would be valuable.In order to address the reviewer's comment, we added more informa3on to the user manual about the data format and data handling with an annotated exemplary image of the data folder structure (user manual, sec3on '7.Data handling').We also explain data format compa3bility with the SIMToolbox reconstruc3on so^ware and the required data and metadata structure to facilitate an automa3c read-in by the so^ware.Furthermore, we included an addi3onal sec3on to the user manual where we explain the structure of the distributed so^ware folder and included files (user manual, sec3on '4.Distributed files and required folder structure) 2.15) Exploring the possibility of exporEng the LabVIEW soWware as an executable could enhance usability.We created an executable openSIM so^ware version with corresponding user manual which we provide on the GitHub repository (see more informa3on above) 2.16) Clarify the purpose of indicator "I4" and its rela3onship with the SLM triggering the camera.We added more informa3on about indicator 14 to the user manual to clarify usage (now a^er some changes indicator 15 in current user manual version).

2.17) Address the unclear funcEonality of "Enabling/Disabling test mode." If possible, allow running the soWware fully without hardware or rename it to "LED TesEng mode."
We already implemented a so^ware mode which enables running the so^ware without hardware.The debugging modes is to facilitate tes3ng and debugging of the so^ware and the individual devices (i.e.SLM, NI DAQ, camera).It can be useful to connect only some of the devices (e.g.only NI DAQ is connected and tested with the so^ware, while the SLM and/or camera is not connected).However, in the default (non-debugging) mode the openSIM so^ware will return an error message and stops when devices are not connected.In the debugging mode, the so^ware can be used despite the corresponding device not being connected.The term 'test mode' is indeed inaccurate at it is only a fan test mode.We renamed the control in the so^ware user interface and explained the mode clearer in the user manual.

2.18) Consider populaEng the troubleshooEng secEon, offering soluEons to potenEal issues users might face, such as wrong hardware ports or error messages.
In response to the reviewer's comment, we added further informa3on to the exis3ng troubleshoo3ng cases and added addi3onal troubleshoo3ng cases.We also created a troubleshoo3ng sec3on specific for the user manual for the executable so^ware version, since this so^ware version could poten3ally encounter different errors.We also added more custom error message or user prompts to the openSIM so^ware for cases in which the user connects / selects something wrong.This poten3ally prevents LabView internal error messages leading to a more uncontrolled shutdown of the so^ware or missing func3onali3es.

2.19) Clarify why certain opEons are grayed out in the serngs, such as EM gain, AOI width, AOI height, and AUX output source.
For a be9er user-experience and an easier handling of the openSIM so^ware we made the visibility or color (disabled and greyed out) of certain controls and indicators depended on the availability of the corresponding device (e.g.z-stacking op3on is only visible/enabled if a z-actuator as peripheral component is selected or EM gain is only visible/enabled if an EMCCD camera is selected) or depended on certain selec3ons (e.g.control and indicators corresponding to the automa3c pa9ern selec3on mode are only visible/enabled if the automa3c mode and not the manual mode is selected).We added more informa3on to the user manual to clarify this aspect.

2.20) Provide clarity on which cameras may support LabVIEW integraEon among the potenEal addons.
We clarified the camera compa3bility in the manuscript methods sec3on, the user manual (user manual, sec3on '1.Introduc3on to the openSIM so^ware') and the documenta3on (corresponding page of the openSIM website, sec3on 'openSIM so^ware'.We also pointed out the camera-model independent implementa3on of the openSIM so^ware executable.Manuscript methods sec3on 'LabVIEW interface and openSIM control): At the moment we offer several so^ware versions with different func3onali3es in order to provide an adequate op3on for user with diverse requirements.For users who want to modify or customize the so^ware we provide the full LabVIEW project including camera control (exposure 3me, camera gains, binning op3ons) and data handling (pre-formagng the data to be compa3ble directly with the open source SIMToolbox SIM processing algorithm).The first version includes a full camera control for the camera models Andor Zyla PLUS sCMOS (6.5µm pixel size) and Andor iXon3 EMCCD (8µm pixel size).The modular design of the so^ware provides the possibility to include the control of other commercial cameras.For user who want to primarily use the so^ware, we offer an applica3on (exe) of the openSIM so^ware which is not camera model specific.

2.21) Consider adding a Emelapse mode to the GUI.
We implemented a 3melapse mode in the openSIM so^ware (see supplementary figure 5) and added a corresponding sec3on to the user manual.

2.23) A concise readme for the electronics secEon would aid in understanding the files.
We added a readme file to the electronics folder on the openSIM GitHub repository with explana3on of the individual files and their purpose and an annotated image of the folder structure.

2.24)
Ensure that source files are included in the electronics secEon.We ensured that the source files are also included in the electronics sec3on.

2.25) Provide clarificaEon on how the LED is switched and amplified in the electronics design.
We created an addi3onal figure (supplementary figure 10) explaining the synchroniza3on and the 3ming scheme of LED, SLM and camera and explained the background why a synchroniza3on of these components is necessary.We added more informa3on about the LEDs and the LED driver boards to the documenta3on (corresponding page of openSIM website, sec3on 'LEDs').The actual LED amplifica3on is done with a compa3ble commercial LED driver board.In the corresponding sec3on in the documenta3on, we linked the LED and LED driver board specifica3on sheet.Manuscript methods sec3on 'Synchroniza3on camera, SLM and LEDs': SIM images can exhibit ar3facts associated with the illumina3on pa9ern.Thus, the 3ming of the system's sub-components, namely camera, SLM, LED, has to be precisely synchronized (Supplementary Figure 10).The camera's exposure signal is employed to ini3ate the sequen3al projec3on of the pa9erns chosen within the pa9ern sequence.LCOS microdisplays cannot con3nuously display pa9erns since each pixel state must be inverted a^er every image to avoid a charge build-up.To facilitate this, the illumina3on source must be temporarily disabled during the refresh cycles, necessita3ng a precisely synchronized 3ming scheme for both the microdisplay and LEDs.The 3me period, which delineates the intervals for displaying the pa9ern or the inverted pa9ern, is determined by predefined 3ming schemes provided by the manufacturer of the SLM (ForthDimension).Manuscript methods sec3on 'Electronic components for the openSIM': The LEDs are powered and controlled using the boards and connectors supplied in the DK114N3 development kit (Luminus devices).The kit consists of high current driver boards and cable assemblies for each channel to provide the LED drive current for high brightness.A custom interconnect board was designed to facilitate the connec3on between the elements of the openSIM, such as the data acquisi3on device, LEDs, thermistor and fan for temperature control, SLM and camera.

2.26) Consider using thicker wire lines on the PCB for larger signals like those for the fan and LED.
We thank the reviewer for the sugges3on.The power supply for the fan and LED does not go over the interconnect PCB.The PCB only provides enable and PWM signals for the LED and fan.For the power supply cables with appropriate dimensions are used.Addi3onal informa3on and a schema3c presen3ng the func3on of the interconnect board was added to the documenta3on to improve the understanding (corresponding page of openSIM website, sec3on: 'Interconnect PCB') 2.27) Adding LED spectra to match fluorophores would be beneficial, either here or in the manuscript.Addi3onal informa3on about the used LEDs (emigng area, domina3ng wavelengths) and the spectral distribu3on was added to the manuscript methods sec3on and the documenta3on (corresponding page of the openSIM webpage, sec3on 'LEDs').An addi3onal figure (supplementary figure 11) was created depic3ng the LED spectra.Manuscript methods sec3on 'Op3cal components for the openSIM': Three high power PT54 LEDs (PT-54-TE, Luminus Devices; dominant wavelengths: red-amber  != 613nm, green  != 525nm, blue  != 460nm, emigng area of 5.4 mm2) are used to generate the illumina3on light (Supplementary Figure 11).

2.28) In the image gallery, clarify whether the 4 angles and 14 paderns shown represent a single reconstrucEon or serve as examples.
More informa3on was added to the corresponding figure cap3on to clarify this aspect.We also included an addi3onal sec3on in the user manual (sec3on '5.Illumina3on pa9erns') where we give more background informa3on on the crea3on of the provided pa9ern sequences (repz files) and the handling and automa3c saving op3on in the openSIM so^ware to enable an automa3c read-in of pa9ern related informa3on by the SIMToolbox so^ware necessary for SIM image reconstruc3on.

2.29) Provide the opEon for raw data alongside images.
We uploaded exemplary raw datasets of different sample types (100nm beads, fixed tubulin, zebrafish z-stack) onto Zenodo containing the raw data and reconstructed data with corresponding image acquisi3on and image reconstruc3on parameter.

2.30) Address the issue of images appearing small in the NoEon website; consider incorporaEng scaling opEons for beder visualizaEon.
The scaling of images in No3on was improved and the sizes of the images were adjusted to each other.In case there was more than one image per point, the images were inserted as one image a^er edi3ng to improve scaling.Furthermore, more annota3ons were added to the images to further improve the understanding.

2.31) QuesEon the use of a potenEally expensive DIY projector; suggest considering customizaEon of a DMD projector along with LED modificaEons for cost-effecEveness.
In order to address the reviewer's comment, we discussed this aspect in the manuscript method sec3on.Manuscript method sec3on 'Op3cal design of openSIM': LCOS are most commonly used for SLM-based pa9ern genera3on due to their high level of performance.The use of DMDs for SIM [18][19][20][21] would be an alterna3ve.They are more cost-effec3ve and the implementa3on of the 3ming scheme is less difficult.Conversely, LCOS microdisplays exhibit reduced diffrac3ve efficiency, resul3ng in fewer diffrac3on losses into higher orders that may not be captured by the imaging lens 22 .

Reviewer #3
3.1) The name "OpenSIM" is not parEcularly unique.A quick google search will show that it is actually being used in a mulEtude of different contexts.While this by itself is not necessarily a problem, it is, however also already being used for a Matlab based SIM reconstrucEon algorithm described by Lal, Shan and Xi (IEEE J.Quantum Electron.22, 50-63 (2016)), who have also just published a 3D extension of this in Nature Methods in July 2023.So, I suggest the authors find a more suitable acronym or maybe leave out the acronym enErely from the Etle.We thank the reviewer for the feedback.To avoid any ambiguity, the name openSIM in 3tle was exchanges with open-source SIM, in response to the reviewer's comment.

3.2)
The system requires two fairly expensive soWware packages, which have not been counted into the bill of materials: Matlab and LabView.Both are currently being distributed as subscripEon based soWware packages, which adds up considerably in the long-term.Thus, it would have been preferred if the authors had used enErely free and openly accessible soWware, e.g.wriden in Python.This aspect was also raised by reviewer #2.We thank the reviewer for this insigh`ul comment and completely agree with the reviewer's opinion.To address the reviewer's comment, we developed an addi3onal so^ware version based on which we build an applica3on which we now provide on the openSIM repository Please refer to the response discussed above for more informa3on (2.3).
Many thanks for the detailed processing of the comments and points of criticism that arose in the previous review.The manuscript has made a significant leap in quality thanks to the thorough editing.In particular, the points raised by Reviewer #1 regarding the theoretical treatment and the subsequent discussion in the document contribute to a significant increase in quality.
With the update of the documentation on Notion, the project can be used as a prime example of good open-source documentation.The authors have gone to great lengths to ensure that others can reproduce the project.With this information, other developers should also be able to migrate the existing software to e.g.Micro-Manager/Pycromanager or a complete Python-based framework.Since parts of the software, the documentation and assembly guides are now spread along Zenodo, Github and Notion, perhaps the authors can have one central spot (i.e.landing page), where users see the tree of different information at first sight.
After going through all the changes and reviewing the detailed documentation, as well as processing the now available raw data with our own algorithms and installing the Labviewer routine, I support a publication in Nature Communications.

Reviewer #3 (Remarks to the Author):
I have carefully read the author's response to my own comments as well as to the comments and concerns raised by the other reviewers.I have also read the revised manuscripts.The authors have done an excellent job addressing all concerns and I deem the revised manuscript worthy of publication in Nature Communications, if the authors can add one more point to their manuscript: After reading reviewer 1's comments it is pretty clear that reviewer 1 was mislead by the original manuscript.It seems that reviewer 1 thought that this manuscript describes an interference-based super-resolution SIM microscope, which is not the case.The system is, indeed, based on a pattern-projected based approach as the authors have stated nicely and quite well in their response to reviewer 1.However, just explaining this fact might not be sufficient to not get other readers confused.The main reason for this is that the acronym SIM is being used in a large number of applications ranging from super-resolution microscopy all the way to determining object height of objects on a conveyor belt.There is a better term for what the authors are describing here: optical sectioning SIM, or OS-SIM.I think if the authors added the simple two more letters to their description and listed 1-2 original OS-SIM papers as references, then most of the current confusion should be lifted.

Response to Referees Le,er
Reviewer #1: The authors have comprehensively addressed all points raised by me.And a7er reading the authors' responses to the other two reviewers, I think they are also reasonable and adequate.I am happy to recommend publica?on.

Reviewer #2:
Many thanks for the detailed processing of the comments and points of cri?cism that arose in the previous review.The manuscript has made a significant leap in quality thanks to the thorough edi?ng.In par?cular, the points raised by Reviewer #1 regarding the theore?caltreatment and the subsequent discussion in the document contribute to a significant increase in quality.With the update of the documenta?onon No?on, the project can be used as a prime example of good open-source documenta?on.The authors have gone to great lengths to ensure that others can reproduce the project.With this informa?on,other developers should also be able to migrate the exis?ng so7ware to e.g.Micro-Manager/Pycromanager or a complete Python-based framework.Since parts of the so7ware, the documenta?onand assembly guides are now spread along Zenodo, Github and No?on, perhaps the authors can have one central spot (i.e.landing page), where users see the tree of different informa?on at first sight.We thank the reviewer for raising this point.We restructured the first page of the openSIM webpage so that it serves as a central point of the documenta=on which guides the user to the individual parts of the documenta=on on the different pla?orms.
A7er going through all the changes and reviewing the detailed documenta?on,as well as processing the now available raw data with our own algorithms and installing the Labviewer rou?ne,I support a publica?on in Nature Communica?ons.

Reviewer #3:
I have carefully read the author's response to my own comments as well as to the comments and concerns raised by the other reviewers.I have also read the revised manuscripts.The authors have done an excellent job addressing all concerns and I deem the revised manuscript worthy of publica?on in Nature Communica?ons, if the authors can add one more point to their manuscript: A7er reading reviewer 1's comments it is preVy clear that reviewer 1 was mislead by the original manuscript.It seems that reviewer 1 thought that this manuscript describes an interference-based super-resolu?onSIM microscope, which is not the case.The system is, indeed, based on a paVernprojected based approach as the authors have stated nicely and quite well in their response to reviewer 1.However, just explaining this fact might not be sufficient to not get other readers confused.The main reason for this is that the acronym SIM is being used in a large number of applica?ons ranging from super-resolu?on microscopy all the way to determining object height of objects on a conveyor belt.There is a beVer term for what the authors are describing here: op?cal sec?oning SIM, or OS-SIM.I think if the authors added the simple two more leVers to their descrip?onand listed 1-2 original OS-SIM papers as references, then most of the current confusion should be li7ed.We thank the reviewer for the sugges=on and agree that the term SIM finds applica=on in a mul=tude of contexts which can lead to ambiguity.We would like to clarify that the openSIM system does not solely provide op=cal sec=oning capabili=es but also an improved lateral resolu=on.Thereby, it can be considered as SR-SIM system in our perspec=ve.OS-SIM systems normally u=lize illumina=on paHerns that are rela=vely coarse 1 whereas SR-SIM systems use illumina=on paHern with a high spa=al frequency 2 .The open-source program (SIMToolbox) we are using to process the SIM data provides OS-SIM and SR-SIM processing methods.Since an LCOS microdisplay is used which allows to display illumina=on paHerns with arbitrary spa=al frequencies in combina=on with the op=on to apply different processing algorithms, openSIM offers both OS-SIM but also SR-SIM capabili=es.For the data we are presen=ng in the manuscript we were using illumina=on paHerns with a high spa=al frequency and a SR-SIM reconstruc=on algorithm.We indeed did not men=on this aspect in the methods part.In order to place our system in this context and to improve the clarity we incorporated addi=onal informa=on about OS-SIM and SR-SIM, with respec=ve relevant references and added more details about the used spa=al frequency and processing algorithm for the presented images.Manuscript methods sec=on 'Illumina=on paHern´: The chosen illumina=on paHerns had a high spa=al frequency.Manuscript methods sec=on 'Op=cal design openSIM': Depending on the op=cal configura=on, the spa=al frequency of the illumina=on paHerns employed and the reconstruc=on algorithm, SIM can be used for op=cal sec=oning by reducing out of focus light (OS-SIM) 3,4 and for super-resolu=on imaging by enhancing the resolu=on 5,6 .For OS-SIM rela=vely coarse illumina=on paHerns are used 1 , while SR-SIM u=lizes illumina=on paHerns with a high spa=al frequency close to the diffrac=on limit 2 .LCOS microdisplays provide the flexibility to display illumina=on paHerns with arbitrary spa=al frequencies.Manuscript methods sec=on 'Image processing´: The program provides OS-SIM and SR-SIM processing algorithms.For the presented images, the SR-SIM reconstruc=on method was used.